今天跟高中同學一起去烤肉，決定早一點開始寫文章，壓線送出，趕稿地獄在昨天已經深刻體會到了 XD

JWT 驗證流程

昨天提了 JWT 的格式，今天來講一下 JWT 的驗證流程，我們已經知道 JWT 是無狀態的一種資料格式，因此我們就拿這串的 Token 進行身份的驗證。當然，這是認 Token 不認人的驗證方式，因此若是你的 Token 被拿走，你的身份就會被盜用，這也是 JWT 最大的缺點。
下面這張圖是 JWT 在系統內運作的流程。

Refresh Token 以及 Access Token

而 JWT 有一個取得 Token 以及交換 Token 的規範，分別稱為 Refresh Token、Access Token，一個負責換新的 Token，另一個 Token 則是讓我們能夠被授權取得資源，這部分我們直接看制定這個規範的文件以及圖片，如下圖。

我們從圖中可以看出以下的流程，我們來看原文怎麼寫的。

• (A) 客戶端向負責授權的 server 請求 access token 並提供授權

• (B) 負責授權的 Server 向客戶端完成驗證，若驗證後將會給予一組 access token 以及 refresh token。

• (C) 客戶端會藉由 access token 將請求給 resource server。

• (D) resource server 會驗證這個 access token，若驗證過後將給予請求回應，並提供客戶端需要的資源。

• (E) 步驟 (C) 與 (D) 可以一直重複進行驗證，直到 access token 過期。如果客戶端知道 access token 過期則直接跳到步驟 (G)，並且另外發出一個受保護的資源請求。

• (F) 由於 access token 無效，因此 resource server 將回傳一個無效的 token 錯誤訊息。

• (G) 客戶端將藉由 authorization server 認證並請求一個新的 access token 並給予 refresh token，而客戶端驗證需求是基於客戶端的類型以及 authorization server 所制定的策略。也就是說客戶端的驗證方式可以據你的需求去進行調整。

• (H) Authorization server 將會驗證客戶端以及你的 refresh token，若是驗證成功，則發放新的 access token（某些狀況下，可能是給你新的 refresh token）

今天講了 JWT 的運作流程以及 token 的發放方式，其實從原文來看，並沒有很嚴格制定 JWT 協定一定需要發放 access token、refresh token，通常 access token 的時效都較短，可能只有幾分鐘，而 refresh token 則是較長，可能會是幾週。
有一些做法是僅發放 refresh token，直接將 refresh token 也作為 access token，當 refresh token 快過期時，則由客戶端重新發送請求，用舊的 refresh token 去拿回一個新的 refresh token，這個就依照各個專案的使用場景進行更動囉。
明天進入 JWT 的實作囉！